Design Rationale Management in Concurrent Engineering

The ability to capture and use design rationales, part of what we call Design Rationale Management (DRM), is an important facet of Concurrent Engineering. Galileo2 is a language for constructing interactive design advice systems for Concurrent Engineering, based on a generalization of constraint processing. We briefly describe the features of Galileo2 which make it especially suitable for constructing Concurrent Engineering applications and supporting DRM. We also sketch an example interaction with a typical application program written in the language; this example scenario shows how an advisor written in Galileo2 uses DRM among other methods to support consultation, coordination, and negotiation among multiple engineers who are expert in different aspects of the product life cycle. Galileo2 is a generic language for constructing constraint-based design advice systems for Concurrent Engineering (CE). Design advisors have been written in Galileo2 for a wide variety of application areas[1, 3, 6]. These advisors essentially “look over the designer’s shoulder,” monitoring user decisions for compliance with CE requirements, inferring the consequences of these decisions whenever possible, and offering suggestions about what to do in the event the user violates a constraint. Galileo2 is especially attuned to supporting coordination between multiple users from different CE perspectives[2, 5]. A paper describing a real-world Design For Testability (DFT) application which uses this technology[8] recently won a national paper competition at AutoTestCon ’91. To support Concurrent Engineering including DRM, the Galileo2 system provides: frame-like structures with full property inheritance; atomic, compound, and quantified constraints over structured and unstructured objects; conditional existence of frames and scalar objects[4]; heterogeneous attribute value types; the ability to run autonomously on small problems and interactively on larger problems; mixed-initiative interaction; design history recording with recapitulation for purposes of design audit, redesign, reuse, and maintenance; multiple perspectives on the same design task/artifact; user-directed disabling of constraints, provided reasons for these decisions are recorded for later use in design audits and/or negotiation with representatives of other life-cycle perspectives; machine-generated suggestions for design patches; automatic rationale for machine-generated design decisions; explanation of machine-generated requests for user information; support for arbitrary design methodologies and styles; database interfaces together with query capability; and feature-based CAD capture of functional design decisions with machine-generated drawing modifications to be accepted at user option. Newer work has added provision for imprecise/uncertain values and relations and varying degrees of constraint satisfaction[7]. To illustrate how Galileo2 supports DRM, we will consider a design advisor written in Galileo2 to assist in the concurrent engineering of printed wiring boards (PWBs). This program, called KLAUS, supports interaction with several members of the design team, including designers, manufacturing engineers, and test engineers. We will briefly see how the differing perspectives of each team member are supported, and how KLAUS provides the capability for each representative of the CE team to record decisions and the rationale behind them so as to be recapturable by other team members. Several points deserve emphasis about this scenario. First, this scenario presents only one of very many possible orders of interaction with KLAUS. Second, we show only a few steps in this interaction. Finally, although the figures in this paper are not actual screen dumps, KLAUS and Galileo2 are fully implemented, and these figures faithfully represent the various interfaces presented to the manufacturing, testing, and design users. In the following scenario, we assume that the project leader has set up a database entry for a new project. We take up the story when the test engineer, who in this case happens to be the first team member to make